Scaffolding Project Based Learning with the Rational Unified Process. Experience from 5 years of Student Projects in Software Engineering

The last years have seen a growing interest in Project Based Learning (PBL). Project Based Learning is associated with a constructivist approach, focusing on student driven learning in a collaborative setting. However, to provide real learning in a setting of higher education, the projects should be sufficiently complex and demanding. How can this be achieved without exposing the student to high risks of failure? The empirical background for this study is a two-semester course in software engineering at the Norwegian School of IT, with data collected over a period of 5 years with 1400 Bachelor students. The course is case based and is focused on designing and programming a complex solution. The pedagogy is based on the Rational Unified Process, focusing on iterative and incremental development. Building on Bruner’s concept of scaffolding, we propose that PBL may be successfully scaffolded by a formal software engineering method. In particular, the iterative and incremental structure of modern software engineering may serve as a basis for effective project learning. Our contribution is summarized with five types of scaffolding in PBL in a SW engineering context. Introduction Software engineering is one of the most complex tasks man ever set out to perform. Simplified, it may be described by two separate challenges First, to translate a real world problem into a design for a software solution, then actually build, test and deploy the solution into the real world (Brooks 1987). Since the discipline was born in the 1960s, it is well documented that building large information systems is a high-risk undertaking, demanding both technical and social skills. Even after 50 years of experience the failure rates of software projects are still surprisingly high (Sommerville 2001; Standish_Group 2001). The challenges of teaching software engineering reflect this situation. From a pedagogical point of view the main objectives of a typical software engineering course are a) to integrate the knowledge and skills from various computer science modules and b) to teach the students the process steps and artifacts of software engineering. Both NOKOBIT 2006 20.-22. nov. Molde 2 objectives represent real pedagogical challenges, because the first one is analytically quite demanding for the students, and the second one is – if taught as theory – excruciatingly boring. This has led to a number of innovative approaches. Most of them build on pedagogical principles from constructivist thinking (Vygotsky 1978; Blumenfeld et al. 1991; Dewey 1997); the students should “learn by doing” (not being lectured for), they should construct a concrete artifact, they should work collaboratively (not individually) and the role of the teacher should be as facilitator (not authoritarian). The aim of this paper is to show how PBL may be scaffolded with a formal method from software engineering, the Rational Unified Process. Scaffolding, a concept originating in the work of Bruner and colleagues (Wood et al. 1976), means that a model for the desired task is being provided as part of the instructional design, and responsibility for the process is gradually being shifted to the students. Our key proposition is that a highly structured process – contrary to common belief – is a very effective learning strategy in PBL, both in the sense that it gives the students confidence and in enabling them to build amazingly complex solutions. Our approach is interpretive, and motivated by a pedagogic interest to improve a challenging pedagogic field. Rather than testing a hypothesis we try to understand a practice, and to contribute to the improvement of software engineering in higher education. Research review First we review briefly the general literature on project based learning and comment on the more specific research on project based learning in software engineering. Then we define and discuss the concept of scaffolding. PROJECT BASED LEARNING (PBL) There are many definitions of PBL in research literature. A key feature is that PBL uses projects as the basic organisation for learning. The Buck Institute of Education defines it as “a systematic teaching method that engages students in learning knowledge and skills through an extended inquiry process structured around complex, authentic questions and carefully designed products and tasks” (Markham 2003). This particular definition captures well the two pedagogical dimensions that must be balanced in any specific instance of PBL: Whereas students engage in an extended inquiry process to investigate authentic questions – an undertaking requiring initiative and creativity on part of the students and flexibility and appreciation of different approaches on part of the school – there is also a strong element of structure: PBL is a systematic teaching method, the questions to be addressed by the students can be seen as structuring the inquiry process, and products and tasks are carefully designed. PBL has three essential components (Blumenfeld et al. 1991; Markham 2003). First, there is a problem or a question that drives and organises the activities. Second, the result NOKOBIT 2006 20.-22. nov. Molde 3 of these activities is an artifact that answers or satisfies the initial problem or question. Third, the activities reflect a real-world production process to solve a similar problem. PBL has commonalities with other related pedagogical approaches, such as Problem Based Learning and Work Based Learning (Helle et al. 2006). They all build on the assumption that a real world problem provides both student motivation and an arena for learning. The role of the teacher is also different than in traditional classroom settings, (s)he is acting in a more facilitating manner, rather than in an authoritarian one. There are also differences between the approaches. While PBL focuses strongly on the construction of an artifact, Problem Based Learning does not. In Work Based Learning this may vary, depending on the external partner. Also, while the learning process in both PBL and WBL aims to give the students an authentic experience of a real production process, Problem Based Learning is much more focused on open enquiry. These relationships are illustrated in table 1. Attribute Project Based Learning Problem Based Learning Work Based Learning Based on a real world problem Yes Yes Yes Results in a concrete artifact Yes No Partly Learning reflects the real production process Yes No Yes Table 1. Relationships between PBL and related pedagogical approaches There has been considerable interest in PBL the past decade. Proponents have claimed that PBL increases student motivation, develops team and communication skills and generally improves learning and critical thinking (Blumenfeld et al. 1991; Helle et al. 2006). PBL IN SOFTWARE ENGINEERING COURSES In software engineering courses PBL has been reported to work successfully, see for example the annual Conference on Software Engineering Education and Training (CSEE&T), which usually includes a track for software engineering projects. The approaches share a number of attributes. They aim to present larger cases that emulate real-world problems, they emphasize collaborative learning, they aim at integrating knowledge from different parts of the computer science curricula and they also explore new relationships and roles between students and lecturers (Morrison 2004; Gulbahar and Tinmaz 2006). For example, Sindre et al. reports from a cross-course project that fully integrates four other disciplines at the NTNU in Norway (Sindre et al. 2003), thus achieving a scaling effect to make the case more realistic. Interestingly, Morrison identified some pitfalls of collaborative systems development; free riders, configuration management and time management (Morrison 2004). NOKOBIT 2006 20.-22. nov. Molde 4 SCAFFOLDING A pedagogical challenge for PBL in software engineering is that the task in itself is quite demanding, leading to a high risk of failure for the student groups. What are effective strategies for coping with this challenge? Learning in a project relates to a set of skills necessary to successfully complete the project. These skills may be reflected in a set of formally defined learning objectives. Learning can be regarded as happening in a zone of proximate development (ZPD). The zone describes the ‘space’ between what learners can achieve without help and what they can achieve with the help of a tutor/supervisor (Vygotsky 1978). The skills and knowledge defined by the learning objectives of a PBL design may be found at the outer limit of the students’ ZPD as the project starts. As students learn throughout the project, with course staff providing support for them to reach beyond what they are able to do alone, the students’ skills develop, and the outer limit of the ZPD expands. When a project course is completed, the successful completion of a (structurally) similar project may thus be attainable to the students without much staff supervision. Providing the support for the learner to gradually master what is needed to complete a task has been denoted scaffolding by Bruner (Wood et al. 1976) who builds on Vygotsky’s work. Scaffolding was initially used as a metaphor for the process where an adult assists a child to carry out a task that is outside the current capabilities of the child. This allows the child to concentrate on the elements that is within reach, gradually increasing his skills. “At best, this process continues until he becomes acquainted with and skilled in all aspects of task activity to the point where he can initiate and control his own behaviour in the absence of an instructor” (Stone 1993). In a higher education context scaffolding includes activities such as providing directions, keeping the student on track, offering assessments, increasing efficiency and reducing risk. Scaffolding typically implies the use of artifacts such as computers and documents, as can be seen in CSCL (Computer Supported Collaborative Learning). SE project courses vary in respect of requirements for students to follow a certain process model and, if a specific model is required, how many templates and guidelines are provided and how strictly they should be adhered to. Iterative software development approaches represent current practice within the field of SE (Jacobson et al. 1999; Larman 2004), and thus many SE courses are based on iterative process models in order to provide students with sought-after competence. Requiring strict adherence to a process model within PBL might however raise questions about the necessary room for challenge and for developing individual approaches and solutions. Anticipating our conclusion, we argue, based on empirical data, that relatively structured iterations in student projects at a certain stage of SE education provide opportunities for scaffolding that greatly benefits learning results. Gradual mastery of the basic steps of conducting project tasks and producing project artifacts in early phases of a project enables students to explore other, equally challenging dimensions of project work. A structured process allows students to come up with (sufficiently) creative and unique NOKOBIT 2006 20.-22. nov. Molde 5 solutions with little risk of getting lost in the basics of project artifacts and with less risk of the whole project failing. Method The empirical part of this research is a case study of a software engineering module in the Norwegian School of IT (NITH), in the period 2002 to 2006. Two of the authors were lecturers in the course. The course has been under continuous improvement. The experiences from each year were discussed with involved staff and external sensors at the end of the year. These views, supplemented with student evaluation results, were then fed back in the form of improvements for the next year’s running of the module. In 2006 we took a longitudinal view on the module, analysing the trends and patterns (Miles and Huberman 1994). Data collection was performed with a number of sources: • Student and marking statistics, and student satisfaction data, constitute a quantitative resource. • The projects were very well documented by the student groups. Each project group wrote six iteration reports, a final project report, and also individual and group reflection notes. In particular, the reflection notes were a valuable source, because they described the learning process in detail, as experienced by the group and by each individual. The individual reflection notes were treated confidentially in the project, and were quite open in describing the interaction between students. In later citations the quotes are translated from Norwegian. • Since two of the authors were also lecturers, participative observations of literally hundreds of tutoring sessions with project groups constitute an important part of our empirical material. We acknowledge the limitations in this type of “data”, and use these observations only as a background. First, we analysed the student marks and student feedback data in the years 2002-2006. In addition we analysed the comments given by students in their evaluation feedback sheets. This gave us a longitudinal view of the results. Then we reviewed in detail the reflection notes for two full cohorts 2005 and 2006, both group and individual notes. Each reflection note was usually between one and two pages, enabling us to do a detailed qualitative analysis of the issues identified as relevant for the topic of scaffolding. These included support for main and micro structure of the project, the degree of perceived integration with other courses, challenges associated to product and document integrity, and group cooperation. The case: A Software Engineering Project Course at the Norwegian School of IT The Norwegian School of IT is a private university college with three campuses: in Oslo, Bergen and Stavanger. Specialising in IT education, the college works closely with the industry to develop relevant courses, offering two Bachelor programmes, in IT and in SW engineering. NOKOBIT 2006 20.-22. nov. Molde 6 The PJ300 course was developed in 2001, with the aim of integrating the different courses of the second year of the IT Bachelor. These modules are Programming (Java), Databases (Oracle), Systems Analysis and Design (UML), Technology (Data communications) and Technology and Organisation. The structure of the Bachelor program is (somewhat simplified) shown in table 2. 3 year Programming or S.A. IT in organisations IT security, XML etc. Work based project 2 year Programming and databases Techn. and organisation Technology Systems Analysis Project SE Engineering 1 year Programming Databases Technology Systems Analysis and projects Table 2: Structure of Bachelor of IT The main objectives for the PJ300 module were to a) to provide a learning space for the students to integrate the knowledge and skills from the other 5 modules and b) to teach the students the basic skills of software engineering. As described in the introduction, both objectives represent real pedagogical challenges. The solution was a large software development case, large enough to last a year and including knowledge and skills from the other parallel modules. In addition the case needed to be constructed in such a way that students of all levels of skill would be comprehensively challenged. This implied that the solution should be analysed and designed with UML and patterns (Larman 2001), programmed in Java and Oracle and run in a complex environment of PCs, a database and web servers. At the start of the 2 Bachelor year this challenge is way above the skills of the students, and the project was designed so that teaching in the other parallel modules provided the students with the necessary skills just-in-time for the project. To structure this development process we chose the Rational Unified Process (RUP). There were two reasons for this choice. First, RUP is a modern and widely used software engineering framework in the IT industry, thus supporting NITH’s aim of working closely with industry. Second, RUP provided a quite extensive set of guidelines and templates for the development process (Jacobson et al. 1999). The number of students (decreasing annually, because of the general decline of the number of IT students in Norway) and the specifics of the case during the five years of operation are described in table 3. NOKOBIT 2006 20.-22. nov. Molde 7 Year Number of students Case New technology introduced 2002 632 Airline tickets Java 2003 379 Hotel and activities booking Java servlet 2004 255 Airline tickets Web services 2005 102 Web based exam test system WAP application 2006 71 Sushi restaurant and take-away J2EE application Sum 1439 Table 3. Number of students and project case. The structure of the project year is detailed and mandatory. The case is given by the course leader, and is quite detailed, describing the system in 5 modules. The groups are free to choose how many of the system modules they intend to develop, the modules being increasingly demanding. The structure of the project year is shown in table 4. In the first week the students fill in a form, and are put into relatively homogenous groups of four students, in accordance with personal motivation and technical skills. A key feature of PJ300 is that it follows an iterative structure. The project is structured by six iterations, in accordance with RUP, each iteration being a “mini project”, starting with objectives and requirements, proceeding with design, programming and testing, and ending with a formal meeting with the “customer”, i.e. the tutor. Each iteration is done in one week blocks, where the students work the full week with the project. Week Iteration Artifact objective 34 1 Project plan and GUI prototype 41 2 Draft SW architecture, application module 1 Autumn semester 50 3 SW architecture, application modules 1+2 3 4 Application modules 1+2+3 9 5 Application modules 1+2+3+4 (+5) Spring semester 16 6 Finished application Exam 20 Product demo Table 4. Structure of PJ300 during the year Each iteration is documented in a short report, UML models and source code, in addition to iteration plans. The iteration result is deployed at a web site that the group maintains during the project. At the end of the spring semester the students post their final report and reflection notes, then the web site is closed and made available for the two sensors. At the exam the students present their work orally and demonstrate the completed application. The sensors pose questions both on process and technology, and give final feed-back and grades. NOKOBIT 2006 20.-22. nov. Molde 8 Findings and discussion This section presents the findings of the case. Our main finding is that various types of scaffolding have proved effective for learning in this project. We will systematically present and discuss these types. The results of the PJ300 have been quite good, as shown in table 5. Year A B C D E F 2002/03 * 2004 36 % 35 % 22 % 5 % 2 % 1 % 2005 38 % 34 % 14 % 12 % 2 % 2006 25 % 45 % 15 % 14 % * Norway changed its grading system in 2004, so grades from 2002 and 2003 are not commensurable. The profile, however, is the same as the following years. Table 5. Results of PJ300 The quite satisfying results shown in table 5 are even more impressive when we take into consideration that the actual students of NITH have medium to low grades from high school, and also much poorer results in the programming modules than in the project course. We should, however, add that projects generally achieve better marks than other courses, partly due to the “free rider” phenomenon. The results of the students’ feedback evaluation sheet give the same picture. They have consistently reported quite high satisfaction scores. Maximum score is 6 (very satisfied) and the lowest is 1 (quite unsatisfied). For the two years 2005 and 2006 the scores were: Year * Content and relevance Lecturer Exercises My own learning Over all assessment 2005 5,2 5,1 3,9 5,2 4,8 2006 5,8 4,3 4,3 5,8 5,4 Average NITH 4,5 4,4 3,7 4,0 4,0 * The student feedback was not measured the same way before 2005 Table 6. Student evaluation results It is notable that while the scores for content/relevance, my own learning and overall assessment is significantly higher that the NITH average, the scores for lecturer and exercise do not show better results. We attribute the results to various types of scaffolding, listed below. • Main structure (phases and iterations) is scaffolded by RUP NOKOBIT 2006 20.-22. nov. Molde 9 • Micro structure (activities) is scaffolded by RUP • Technical development is scaffolded by other courses, as shown in table 2 • Product integrity is scaffolded by predefined product modules • Document quality is scaffolded by predefined document structure and web based hand-in and assessment • Group cooperation is scaffolded by homogeneous groups and role definitions MAIN STRUCTURE (PHASES AND ITERATIONS) IS SCAFFOLDED BY RUP Scaffolding may be supported both at a macro (structure) and micro (activities) level (Gutzdial 1994). At a macro level the PJ300 is supported by the iterative structure of RUP, shown in figure 1. RUP is structured in four phases, each consisting of one or several iterations; small mini-projects with a clear objective. Figure 1. Structure of the Rational Unified Process (Rational 2002) As described in the previous section, a key feature of PJ300 is that it follows an iterative structure. The structure of each iteration is relatively uniform through the six iterations. The students usually struggle with the first two iterations, but gradually the iteration structure is routinised and managed. One student group wrote in their reflection notes: “We learned most by working with incremental parts which were developed in iterations. Using RUP helped us to go from theory to practice in a large project that was rather similar to an industrial project” We propose that the repetitive character of iterations gradually increases the students’ confidence, in accordance with the principles of scaffolding described in section 2. It is also congruent with Bruner’s notion of a “spiral curriculum”, where structural elements are repeated (Bruner 1960). Using a software engineering method as a framework for learning has been successful in other settings. For example, in Spain a course using the NOKOBIT 2006 20.-22. nov. Molde 10 iterative and incremental structure of XP was used as a pedagogical technique, as well as a subject for the students (Alfonso and Botia 2005). MICRO STRUCTURE (ACTIVITIES) IS SCAFFOLDED BY RUP A software process such as RUP includes a main structure for a project (iterative and incremental), a set of artifacts to be produced (documents, models, components) and a sequencing of detailed activities. In professional software engineering this structure is established to achieve control over the development process. When implemented in a teaching context, does this impose restrains on the creative and exploratory learning process? Our evidence indicates no. The first two years (2002-03) we left the students free to choose how they wanted to use RUP; they could use only the main structure and improvise the rest, oppositely, they could follow RUP in every detail, using the text book and RUP on-line as resources. The result was disappointing; the groups spent the two first iterations to research and discuss RUP, and were not able to plan and manage productively. The groups’ discussions of RUP were generally poor, because they did not have any real experience using it.